In today's networking environment, there are data service customers that have equipment at many different business sites and at various locations. All of the customer's equipment may be networked by the service provider. Some of the sites may be interconnected via an internet protocol (IP) virtual private network (VPN) service (a layer 3 VPN), and other sites are interconnected through an Ethernet-based layer 2 VPN VPLS (virtual private LAN service). Regardless of the specific interconnecting technology, from the customer perspective, there is only a single virtual private network that is dedicated to the customer. To provide the customer with a single VPN view, interworking is required between the two VPNs. In addition, each of the different VPN types have both positive and negative attributes. For example, while Ethernet-based layer 2 networks provide plug-and-play advantages, it is not as scalable as IP-VPN networks and requires fiber-based transport. As another example, with layer 3 IP-VPN networks, operational scalability is hampered due to IP routing configuration requirements for each IP interface and close coordination required between service providers and customers.
Accordingly, there is a need for an interworking mechanism between layer 2 and layer 3 VPN networks and for an improved method of operating a virtual private network. However, in today's implementation, an external interworking trunk is required to interconnect a layer 2 VPN device and a layer 3 VPN device. There is no device that has implemented a mechanism to perform this interworking function inside a box. The present disclosure is intended to address this issue.